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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



SMS has been very successful in the GSM second generation system, as all mobiles have supported the application 
level and it is possible to send to any GSM handset without the need to check for individual support. This easy to use 
service for non realtime text transmission between GSM users shall be succeeded to in third generation mobile systems 
by a non real-time Multimedia Message Service, MMS. The MMS will allow users to send and receive messages 
exploiting the whole array of media types available today e.g. text, images, audio, video while also making it possible to 
support new content types as they become popular. 

3GPP shall not standardise new services themselves, but instead uses the standardised set of service capabilities features 
on which the new services will be built. 

Multimedia technology a rapidly developing allowing new capabilities, such as multimedia messages, games, 
presentations and services that are now considered to be a part of every day life. Multimedia consists of one or more 
media elements (such as text, voice, image and video), and it is the combination of these media elements in a ordered 
synchronised manner that creates a multimedia presentation. 

A non-realtime multimedia message as observed by the user is a combination of one or more different media elements 
in a multimedia presentation, that can be transferred between users without the requirement for the need to be 
transferred in realtime. The non-real-time multimedia messaging service shall be capable of supporting current and 
future multimedia messaging services, and exploit the advances being made in the world multimedia community, with 
additional mobile requirements. 
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Scope 



This Technical Specification defines the stage one description of the non real-time Multimedia Messaging Service, 
MMS. Stage one is the set of requirements which shall be supported for the provision of non real-time multimedia 
messaging service, seen primarily from the subscriber's and service providers' points of view. 

This TS includes information applicable to network operators, service providers, terminal and network manufacturers. 

This TS contains the core requirements for the Multimedia Messaging Service, which are sufficient to provide a 
complete service. 

Additional functionalities not documented in this TS may implement requirements which are considered outside the 
scope of this TS. Such additional functionality may be on a network- wide basis, nation-wide basis or particular to a 
group of users. Such additional functionality shall not compromise conformance to the core requirements of the service. 

This TS defines the requirements for MMS to be understood as a framework to enable non real-time transmissions for 
different types of media including such functionality as: 

multiple media elements per single message 

individual handling of message elements 

different delivery methods for each message element 

negotiate different terminal and network MM capabilities 

notification and acknowledgement of MM related events (e.g. delivery, deletion, ...) 

handling of undeliverable MM 

personalised MMS configuration 

flexible charging 

The above list is not exhaustive. 

Thus the MMS enables a unified application which integrates the composition, storage, access, and delivery of different 
kinds of media, e.g. text, voice, image or video in combination with additional mobile requirements. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 22.101: "Service Principles". 

[2] 3GPP TS 22.121: "The Virtual home Environment". 

[3] 3GPP TS 21.133: "3G Security; Security Threats and Requirements". 

[4] ITU-T E.164 (1997): "The International Public Telecommunications Numbering Plan". 
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[5] IETF; STD 001 1 (RFC 2822): "Internet Message Format", URL: 

http://www.ietf.org/rfc/rfc2822.txt . 

[6] 3GPP TS 21.905: "Vocabulary" 

3 Definitions and abbreviations 

3.1 Definitions 

Recipient : the recipient is the entity to which a MM has been sent. 

Sender: the sender is the entity that sent a MM. 

User: the user is the MM sender or the MM recipient. 

message element: a message element is a part of a MM consisting of only one media type. 

multimedia message: a multimedia message is a message composed of one or more message elements. 

multimedia message service: A multimedia message service allows transfer of multimedia messages between users 
without the requirement for the multimedia messages to be transferred in real-time. 

media types: a media type refers to one form of presenting information to a user, e.g. voice or fax. 

media formats: within one media type different media formats are applicable for the media presentation, e.g. a picture 
can be GIF or JPEG format. 

network: for the purposes of supporting multimedia messaging, the term network shall be considered to include the 
mobile operator's network and any functionality which may exist outside the mobile operator's network (i.e. fixed, 
internet and multimedia technologies etc.), and the support provided by that functionality for multimedia messaging. 

Value Added Service Provider: see Reference [2]. 

Short code: A string of alphanumeric characters which addresses a specific service of a Value Added Service Provider. 

3.2 Abbreviations 



For the purposes of this document the following abbreviations apply: 

MM Multimedia Message 

MMS Multimedia Message Service 

SMS Short Message Service 

VASP Value Added Services Provider 



High level Requirements 



The following list gives the high level requirements of the MMS. These are requirements which are independent of the 
user's perception of the service: 

- Forward compatible multimedia messaging 

Multimedia messaging mechanisms shall provide the capability to support current and evolving multimedia 
messaging by re-using existing standards as far as possible and proposing extensions (as necessary) to existing 
standards (i.e. the multimedia messaging service shall support the evolution of multimedia messaging 
technologies). 

- Consistent messaging 



ETSI 



3GPP TS 22.1 40 version 5.3.0 Release 5 7 ETSI TS 1 22 1 40 V5.3.0 (2002-09) 

Regardless of the message type / format, MMS shall be capable of supporting integration of all types of 
messaging (e.g. fax, SMS, Multimedia , voicemail, e-mail etc.) in a consistent manner. 

- Universal messaging access 

Within the capabilities of networks and terminals, the user shall be able to experience consistent access to the 
MMS regardless of the access point. 

For example the user should be capable of accessing her multimedia messages through a number of different 
access points, which should include 3GPP systems, fixed networks, the Internet, etc. 

- Interoperability 

The MMS shall support a minimum set of functionality and message formats to ensure interoperability, (e.g. 
deletion of MM, identified standardised message notification, message media types and message content 
formats). 

The MMS shall provide a minimum set of supported formats to ensure fall interoperability between different 
terminals and networks from the very beginning of service provisioning (e.g. JPEG for pictures, MP3 for audio, 
MPEG for motion pictures, etc.). 

The MMS shall support version management by indicating a version number in the MM for interoperability 
piupose. 

- The MMS shall comply with the Virtual Home Environment specified in 22.121[2] 

The non-real-time multimedia messaging service shall be supported using the standardised set of service 
capabilities features. 



General Requirements 



Network operators have many differing requirements, and MMS shall be supported in the network in a manner which 
allows network operators to consider different configurations depending on their network and commercial requirements. 
Thus, an identified set of functionalities and formats shall be standardised to ensure interoperability across networks and 
terminals to support MMS. 

However, some network operators may wish to design and configure networks in different ways, and the subsequent 
requirements are identified to allow flexibility in how the MMS functionality is supported. For example in some 
networks the network operators may wish to implement the MMS functionality within the core network, whereas other 
may wish to place the MMS functionality on the periphery of the core network (e.g. a centralised network model instead 
of a distributed architecture). Further, some network operators may wish to support a limited set of MMS functionality, 
while others may require extensive and elaborate MMS support according to their business models (e.g. basic MMS 
instead of advanced MMS). Interoperability shall always be maintained within this flexible architecture. 

The following sub-clauses use the term "The MMS shall be able to support a request for ..." and similar phrases to 
allow network operators to consider these different network models and business requirements, to permit flexible 
architectures and ensure MMS interoperability. 

The following sub-clauses use the term "This requirement shall be supported at the application layer in the terminal 
(and/or the network), and will not be further elaborated. " and similar phrases to identify those service requirements that 
shall be supported by MMS but do not require standardisation. 

The criterion for identifying these types of requirements is as follows: 

If the requirement corresponds to an interaction and/or command between the terminal and the network applications 
from the same Service Provider (e.g. between the recipient's terminal resident messaging application and the recipient's 
network resident application. The same applies for the sender), then this requirement shall be supported by MMS but 
does not require standardisation. 

The following general requirements shall be supported. 
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5.1 Multimedia message management 

- Terminal-sensitive MM management 

The MMS shall be able to support the capability for the terminal and network to take account of the capability of 
the user's terminal (e.g. deliver a MM / notification in a manner compatible with the terminals capability). 

- Terminal status-sensitive MM Management 

The MMS shall be able to support the capability of the network to take account of the availability, changes of 
the state of availability of the terminal (e.g. store messages if the recipient is not available). 

- MMS Control by the operator 

The MMS shall be able to support a request from the operator to enable/disable MM delivery and submission. 

- MMS Control by the user 

The MMS shall be able to support a request from the user to enable/disable MM delivery and submission. 
This requirement shall be supported at the application layer in the terminal, and will not be further elaborated. 

- Storage of configuration information in the USIM 

It shall be possible to store in the USIM a number of sets of configuration information to allow access to MMS 
services. One of these sets of configuration information is preset by the issuer of the USIM. Such preset 
configuration information set shall only be configurable by issuer of the USIM. 

The preset configuration information is selected unless otherwise specified by the user. 

It shall be possible to retain the configuration information when the UICC is used in different terminals .- 

- Personalise multimedia messaging 

The MMS shall be able to support a request by the user to manage the Service Preferences of his User Service 
Profile related to this MMS [2](e.g. customise his MM environment within the capabilities of the terminal, 
network and MM application. This could be unconditional or conditional e.g. depending on roaming conditions 
or operator restrictions). 

- MM creation 

The MMS shall be able to support the request to create a MM by the user or an application. 

This requirement shall be supported at the application layer in the terminal, and will not be further elaborated. 

- MM Time Stamping 

The MMS shall be able to support the request to include a reliable time value in an MM, a notification and an 
acknowledgement as appropriate. 

- Muhiple Media 

Multimedia messages may be composed of either a single medium (e.g. voice) or multi-media (e.g. Voice and 
video). The MMS shall be able to support a request for media synchronisation / sequencing. 

- Media Type Conversion 

The MMS shall be able to support a request to convert between media types (e.g. Fax to image). The MMS shall 
be able to support an indication from a V ASP that V ASP originated content of an MM should not be converted 
or changed by the MMS service provider before it is delivered to the recipient. 

This requirement shall be supported at the appUcation layer in the network, and will not be further elaborated. 

- Media Format Conversion 

The MMS shall be able to support a request by the user or the application to convert between MM media 
formats (e.g. JPEG to GIF). 
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This requirement shall be supported at the application layer in the terminal and/or in the network, and will not be 
further elaborated. 

- Message forwarding 

The MMS shall be able to support a request to forward multimedia messages or multimedia message elements 
without having to first download the MM to the terminal. 

- Storage of Multi-Media Messages 

The MMS shall be able to support a request for multimedia messages or message elements to be stored until 
delivered to the recipient's terminal, until they expire, or until they are deleted by the user (unless configured 
differently). The MMS shall be able to support a request to store and manage all MMs in a network based 
repository rather than on the mobile terminal. 

NOTE: There is no requirement for the MMS to be responsible for the processing/presentation of the MM 
message, after it has been delivered to the terminal. 

- Prioritisation of Messages 

The MMS shall be able to support a request for MM prioritisation subject to the capabilities of the network (e.g. 
the sender of the MM may request to prioritise the importance of the multimedia messages). 

- Message qualification 

The MMS shall be able to support a request for MM qualification (e.g. subject) for the purpose of advanced user 
experience and awareness. 

- Screening of Messages 

The MMS shall be able to support a request for MM screening subject to the capabilities of the network (e.g. 
automatically delete "junk mail", anonymous messages without delivery to the recipient's terminal). 

This requirement shall be supported at the application layer in the terminal an/or in the network, and will not be 
further elaborated. 

- Validity Period 

The MMS shall be able to support a request by the originator of a message to define validity periods (earliest and 
latest desired time) for message delivery (e.g. if a message can not be delivered within a certain time it will be 
automatically deleted). The MMS service provider shall be able to set the MAXIMUM allowable validity period 
for any message. 

- Multimedia Message Processing by a VASP 

The MMS shall be able to support a request for messages to be processed by a VASP. An example of such 
processing may be where an MM is sent to a VASP before delivery to the recipient so that the VASP can add 
multimedia element(s) to the original message. 

- Replacing MM 

The MMS shall be able to support a request by a VASP to replace a previously sent MM from the VASP with a 
second newer MM. 

- Cancellation of MM 

The MMS shall be able to support a request by a VASP to delete a MM that had previously been sent from the 
VASP but not yet delivered to the terminal. 

5.2 Multimedia message delivery and submission 

- Submission mechanism 

The MMS shall support multimedia messages or messages elements to be submitted from the sender's terminal. 
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- Push Mechanism 

The MMS shall be able to support a request for multimedia messages or messages elements to be automatically 
delivered to the recipient's terminal. 

- Pull Mechanism 

The MMS shall be able to support a request for multimedia messages or messages elements to be delivered to the 
recipient's terminal on request by the recipient. 

Note: Push and pull delivery mechanisms could be identical; the criteria which decide on the type of mechanism 
(push / pull) are either described in the User Services Profile or out of the scope of this specification. 

- Concurrency 

The MMS shall be able to support MM delivery to and from the user's terminal not be restricted during other 
active services (subject to the capabilities of the terminal and the network). 

- Streaming 

The MMS shall be able to support streaming for MM delivery from the MMS system to the terminal. 

Support for streaming for MM upload from the terminal to the MMS system will be considered for future 
releases. 

- Preferred Bearer 

It shall be possible to define a list of precedence for bearers in the configuration parameters for delivery and 
submission of MM (e.g. GPRS, CSD). The terminal shall be able to support automatic bearer selection (i.e. 
without user intervention) based on the order of precedence defined in a list of bearers on the USIM. The user 
shall be able to enable or disable automatic bearer selection. When disabled, manual bearer selection shall be 
available from the list of bearers. 

5.2.1 MM delivery to and submission from a VASP 

- VASP submission mechanism 

The MMS shall support multimedia messages or messages elements to be submitted from a VASP. 

- VASP delivery mechanism 

The MMS shall be able to support multimedia messages or messages elements to be delivered to a VASP. 

- VASP mass distribution 

The MMS shall be able to support a request from a VASP for mass distribution of MMs to recipients. 

- Additional VASP data 

The MMS shall be able to convey additional data associated with an MM from a VASP to the MMS service 
provider and vice versa. 

Note: A possible use case for this could be the option to sent additional charging information from the VASP to 
the MMS service provider. However the data itself is not specified for this release. 

5.3 Notification and Acknowledgement 

The MMS shall be able to support a request to send generic notification and acknowledgement capability to inform the 
user in an appropriate manner of MMS events. Examples may include: 

notify the recipient about received messages (including a description of the message, e.g. content, size, type). 

notify the recipient about actions taken by the MMS, (e.g. due to profile settings like automatic MM forwarding, 
deletion, etc.). 
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acknowledge the sender about successful or failed MM or storage of a MM. 

acknowledge the sender about successful or failed MM submission. 

acknowledge the sender, including a VASP, about successful or failed MM delivery to the recipient terminal 
(subject to the recipient permitting such an acknowledgement). 

acknowledge the sender, including a VASP, about the MM being read/handled at the recipient terminal (subject 
to the recipient permitting such an acknowledgement). 

acknowledge the sender, including a VASP, about successful or failed MM deletion. 

acknowledge the sender, including a VASP, upon request, about the status of a submitted MM (i.e. delivered / 
not delivered). 

acknowledge a VASP, upon request, about the status of a mass distributed MM. A mass MM status report might 
be an aggregated report on the status of individual messages for all recipients on the distribution list of a specific 
mass distributed MM. 

acknowledge a VASP, upon request, about the status of previously submitted MMs, after a VASP had sent the 
MMs being queried. 



5.4 Addressing 



The MMS shall support different addressing formats to identify the sender and recipient. It shall be possible to submit 
one message to multiple recipients. 

The MMS shall support the capability for both MSISDN [4] and e-mail addressing schemes [5] to be used, and the user 
may use either form of addressing to send a message. 

The MMS shall be able to support the request to hide the sender's address from the recipient. 

The MMS shall support a distribution list for mass distribution of MMs from a VASP. The MMS shall support the 
ability for a VASP to have the distribution list been modified by the MMS service provider for this release. 

The MMS may support short code addresses to address Value Added Services. If supported, and routing of messages to 
a MMS VASP service based on a short code address is enabled, the MMS shall be able to translate the short code 
address to a routable address to be used in the transport layer, e.g. a URL 

5.5 Management and Control of a Network Based Repository 

Network based repository is optional. If supported, MMS shall be able to support following functionalities :- 

The MMS shall allow an MMS service provider to configure MMS in such a way that one, several or all 
incoming MMs of a particular user be stored persistently in a network based repository 

The MMS shall allow an MMS service provider to configure MMS in such a way that one, several or all 
submitted MMs of a particular user be stored persistently in a network based repository 

The MMS shall be able to support a request from a sender to persistently store a sent MM in a network based 
repository at the time of sending 

The MMS shall be able to support a request from a user to persistently store a MM for which he received a 
notification in a network based repository 

The MMS shall be able to support a request from a user to upload one or more MMs into a network based 
repository for persistent storage 

The MMS shall be able to support a request from a user to retrieve one or more MMs that are stored in a network 
based repository 

The MMS shall be able to support a request from a user to delete one or more MMs that are stored in a network 
based repository 
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The MMS shall be able to support a request from a user to forward one or more MMs that are stored in a 
network based repository to another destination without being delivered first to that user. 

The MMS shall be able to support a request from a user to view the list of MMs and MM related attributes, such 
as sender, recipient, subject and date/time, in a network based repository 



6 User Profile 

The MMS shall be able to support the ability to create, update, store, transfer, interrogate, manage and retrieve a user's 
multimedia messaging profiles. 

The multimedia messaging profiles shall allow a user to configure and personalise his multimedia messaging 
environment with the multimedia messaging profiles (e.g. which media types and notifications that shall be delivered to 
the recipient , such as voice only or text only). 

If the MMS supports a network based repository of MMs, it shall be possible for the users to configure where incoming 
MMs will be stored. 

The multimedia messaging profiles shall form part of the user's virtual home environment. 



7 Security 



The user shall be able to use and access MM in a secure manner. It shall be possible for the contents of MMs to be read 
only by the intended recipient(s). A recipient shall be informed of the reliability of the identity of the sender in case the 
sender has authorised his identity to be transmitted. 

The integrity of MMs during transit shall be assured to extent of the network capabilities. 

The MMS shall be intrinsically resistant to attempts of malicious or fraudulent use. 

An MMS service provider shall be able to authenticate a VASP connected to it and shall be able to be authenticated by 
a VASP connected to it. The MMS service provider shall be able to authorise the VASP to use various MM services. 
The MMS shall support encryption of the transport layer between an MMS service provider and a VASP. 

Note: Key management is outside the scope of this release of this standard. 

The "Security Threats and Requirements" specified in 21.133 [3] shall not be compromised. 

8 Charging 

The MMS shall be able to support various charging models, including: 

Sender pays; 

both Sender and Recipient pay their respective charges for message delivery; 

Recipient pays for receipt of messages from a VASP when there is a commercial agreement between the 
Recipient and the VASP; 

Sender pays for reply message on a per message basis. 
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The MMS shall be able to support various charging mechanisms. The following charging characteristics may be 
considered: 

message types, length, storage time in the network, etc, 

delivering time, upload / download method, 

MM-sender / -recipient, 

number of messages sent, 

number of messages received, 

roaming conditions, 

location conditions. 

Indication of charging. 

The MMS indicates to the recipient prior to the recipient downloading a multi media message whether the sender 
has paid or the recipient is expected to pay for the message. 

Prepaid subscriptions. 



9 External Interface 

External interfaces for controlling and delivering MM between the terminal and an external device e.g. portable 
computer should be supported. 



10 Interworking 



The standard shall permit interworking with other or existing messaging technologies, messaging services, intelligent 
network services and supplementary services, either located within or outside a mobile network. 

In the case of a VASP, such interworking shall include capability negotiation between the VASP and the MMS service 
provider. Such capability negotiation shall include service version information as a minimum for this release. 



11 Roaming 

Roaming between network operators shall be supported. 
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